DAY12介紹的topic是訂閱-發布模式,發布者不間斷的一直發,訂閱者就有消息可以接收,但發布者並不知道消息是否有確實被接收,而且因為不間斷的發訊息,如果沒有人接收的話其實很浪費電腦資源。
為了解決上述提到的問題,而有了Service通訊界面,使用請求-回應模式,就如客服專員(service)與顧客(client)的關係,今天顧客有需求想提問時,可以撥打客服電話給專員,而專員就會依照你提出的需求給你相對應的答案,因此每通電話(Service)都是專屬於一個專員對上一個顧客,如果還有其他顧客有問題的話,就要再另外打一通電話。
因為沒有很長用到不是很熟,所以就列出來而以,我知道在幹麻的就會備註(有夠不負責任XD)
ros2 service list #列出目前所有的服務名稱
ros2 service list -t #列出目前所有的服務名稱和類型
ros2 service type <service_name> #列出此服務的類型
ros2 service find <type_name> #列出使用此類型的服務名稱
ros2 interface show <type_name>.srv #列出此類型的訊息格式
ros2 service call <service_name> <service_type> <arguments> #請求一次服務Quality of Service settings
Action是類似Service的通訊界面,也是一種請求-回應機制的通訊方式,主要解決service等待時間過長,導致訊息阻塞的情況。Action的訊息格式包含:
Service與Action不同之處在於Action多了一個回饋機制,如Service的客服舉例,如果顧客收到目前還有很多人在等待專員回應的回饋,它可以選擇晚點再撥電話(取消請求)或繼續等待。
和Service大同小異就不贅述了~~
ros2 action list
ros2 action list -t
ros2 action info <action_name>
ros2 interface show <type_name>
ros2 action send_goal <action_name> <action_type> <values>
Quality of Service settings (服務品質設定),可以理解為訊息傳遞的約定參數,用來控DDS系統的行為,如資源消耗的程度、資訊的容錯率(可靠性)。每個節點、話題、服務、動作之間都有關連的Qos,可以手動設定或使用預設值。之前有提過ROS2將原先的ROS1中介軟體層TCPROS/UDPROS改為DDS是為了達到分散、即時的通訊效果,以利用在多機器人協作上,其中最大的優勢就是因為有Qos的支援。不過因為Qos有太多設定可以介紹,我就只說一些比較熟悉的設定與它們的參數:
未來應該會特別介紹到圖中的gazebo(左)和rviz2(右),現在先知道有這些工具就好。
圖中,gazebo中有提供一些方式來發布sensor_msgs/msg/pointcloud2
的Topic,在rviz2則可以接收這個話題資訊,可以看到裡面就有一些Qos的設定。
那我本身也用過實體的光達來發送sensor_msgs/msg/pointcloud2
Topic,但當初不知道有這些設定,好像預設是Reliability-Best effort,導致點雲沒有出現在rviz2中,還以為是光達的ip設定沒弄好,反覆調整了很多次,最後發現應該設成Reliability-Reliable才能成功顯示點雲,因為光達本身傳送的品質不穩定,就造成了rviz2得不到這些品質不及格的資訊...
光是練習使用光達就用了我很多時間呢...